Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix vaccum name in materials #971

Merged
merged 34 commits into from
Jan 6, 2025
Merged

Fix vaccum name in materials #971

merged 34 commits into from
Jan 6, 2025

Conversation

bam241
Copy link
Member

@bam241 bam241 commented Dec 11, 2024

This aims to follow up on #805.

Right now I just pulled @pshriwise branch and rebased it.

Description

This fixes the definition of the Graveyard and the Vacuum, to respectively exactly mat:Graveyard or mat:graveyard and mat:Vacuum or mat:vacuum"

Motivation and Context

the previous implementation would lead to detection of a vacuum where there was not, if the name of the material contained "vacuum" or "graveyard"

Changelog file

  • done ?

This works is sponsored by Proxima Fusion

@bam241
Copy link
Member Author

bam241 commented Dec 11, 2024

@gonuke in the issue you mention a solution that would be backward compatible with most model out there.

Do you have an idea of the backward compatibility we main encounter ? (so I can implement a fix :) )

@gonuke
Copy link
Member

gonuke commented Dec 11, 2024

@gonuke in the issue you mention a solution that would be backward compatible with most model out there.

Do you have an idea of the backward compatibility we main encounter ? (so I can implement a fix :) )

Not really... you all are the users 😀

Maybe it's not reasonable, but I just wanted to make sure it was considered.

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this cleanup @bam241 . I have a couple of minor questions, but otherwise it looks good.

If you want to consider this for the next release, you can update the base branch as v3.2.4-rc1. (It may require a rebase on that branch and reconciling conflicts in the ChangeLog.)

src/dagmc/dagmcmetadata.cpp Outdated Show resolved Hide resolved
Comment on lines 363 to 371
const std::string graveyard_str_{"Graveyard"};
const std::string vacuum_str_{"Vacuum"};
const std::string vacuum_mat_str_{"mat:Vacuum"};
const std::string graveyard_mat_str_{"mat:Graveyard"};
const std::string reflecting_str_{"Reflecting"};
const std::string white_str_{"White"};
const std::string periodic_str_{"Periodic"};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We frequently - but not always - convert these to lower case. Is there a reason to not just define them as lower case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they are only converted to lower case when comparing with a group name read from a h5 geometry.
My guess is the default if not lower case, but allowing some flexibility for the users.

I don't have preferences there, it is really up to you and Pat :)

@pshriwise as you are the initiator of the branch do you have a take on this ?

@bam241
Copy link
Member Author

bam241 commented Dec 13, 2024

@pshriwise @gonuke would it be interesting to add a setter for the Graveyard and Vacuum string.

Allowing users to change them on the DAGMC call instead of having to change the whole geometry definition?

That way we could ensure a little of backward compatibility.

we could keep the default as they are now, but allow some flexibility...

@bam241
Copy link
Member Author

bam241 commented Dec 13, 2024

@pshriwise @gonuke would it be interesting to add a setter for the Graveyard and Vacuum string.

Allowing users to change them on the DAGMC call instead of having to change the whole geometry definition?

That way we could ensure a little of backward compatibility.

we could keep the default as they are now, but allow some flexibility...

maybe @makeclean has also an opinion on my last question :)

@bam241 bam241 changed the base branch from develop to v3.2.4-rc1 January 6, 2025 15:18
@bam241
Copy link
Member Author

bam241 commented Jan 6, 2025

@gonuke I rebased against svalinn:v3.2.4-rc1 and changed the target branch.

about your comment, I guess I am not the one with the most expertise about this.
I keep as they were.

@bam241
Copy link
Member Author

bam241 commented Jan 6, 2025

(btw unit test didn't run after my rebase -- Do they only run on PR vs develop ?.)

@gonuke gonuke merged commit 94f5cac into svalinn:v3.2.4-rc1 Jan 6, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants